home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 3016 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.7 KB
  1. Path: bcfreenet.seflin.lib.fl.us!bcfreenet!z007400b
  2. From: z007400b@bcfreenet.seflin.lib.fl.us (Ralph Silverman)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: ugly constants and header files
  5. Date: 23 Jan 1996 20:14:24 GMT
  6. Organization: SEFLIN Free-Net - Broward
  7. Message-ID: <4e3fj0$a1v@bcfreenet.seflin.lib.fl.us>
  8. References: <k607w0zpkP3U088yn@merlin.magic.mb.ca> <DKvIKs.ACz@hpqmoea.sqf.hp.com>
  9. NNTP-Posting-Host: bcfreenet.seflin.lib.fl.us
  10. X-Newsreader: TIN [version 1.2 PL2]
  11.  
  12. Neil Gall (neilg@hpqt0319.sqf.hp.com) wrote:
  13. : David C. Wright wrote:
  14.  
  15. : > Create a single header file, of the form:
  16.  
  17. :  [ stuff ]
  18.  
  19. : > #ifdef GLOBALS
  20.  
  21. : > int globalvar;
  22. : > anystruct_t *ptr1;
  23. : > enumvars_t evars;
  24.  
  25. : > #else
  26.  
  27. : > extern int globalvar;
  28. : > extern anystruct_t *ptr1;
  29. : > extern enumvars_t evars;
  30.  
  31. : > #endif
  32.  
  33. :  [ stuff ]
  34.  
  35. : > #include this file in any modules that use the #defines/variables/prototypes
  36. : > in question.  In *one* of the modules, use;
  37.  
  38. : > #define GLOBALS
  39.  
  40. : NO NO NO NO NO!!!  Aargh!  This is *really* horrible. Firstly, you've
  41. : got two declarations for the same variables but the compiler isn't aware
  42. : of the fact - if you change one and not the other by mistake you'll spend
  43. : ages looking for that wierd bug.  In short it's a maintenance nightmare.
  44. : Secondly, declaring variables in header files is generally considered to
  45. : be pretty poor style.  I've seen this done so many times, sometimes
  46. : disguised with some macros to avoid the double declaration problem, like
  47. : this:
  48.  
  49. :     #ifdef GLOBALS
  50. :     #define variable
  51. :     #else
  52. :     #define variable extern
  53. :     #endif
  54.  
  55. :     variable int x;  etc...
  56.  
  57. : This is just as ugly, and doesn't get away from the fact that variables
  58. : are defined in header files, which (I'll say this again) is a pretty poor
  59. : coding style and can be error prone.  What happens if you accidentally
  60. : defined GLOBALS in another file ?  You'll get linker problems.
  61.  
  62. : There is one simple, clean and effective way of doing this which will
  63. : make your compiler complain if you do anything silly and which avoids
  64. : all these problems:
  65.  
  66. : Declare all the variables in a header file, say vars.h
  67.  
  68. :     extern int globalvar;
  69. :     extern anystruct_t *ptr1;
  70. :     ...etc
  71.  
  72. : And define them all in a source file, say vars.c, but remember to include
  73. : vars.h.  This way you still define the variable in two places, but the
  74. : compiler will barf if there is a mismatch.
  75.  
  76. :     #include "vars.h"
  77.  
  78. :     int globalvar = 1;
  79. :     anystruct_t *ptr1 = NULL;
  80.  
  81. : What all this boils down to is that C is absolutely pathetic at handling
  82. : multiple source files.  In fact, since it relies on the preprocessor you
  83. : could argue that C has no support at all for multiple source files. 
  84. : Since using variables across multiple files is not very well supported
  85. : in the language, all sorts of wierd and wonderful schemes have been
  86. : designed to do it.  In my mind, what to think about when doing this is
  87. : keeping the interface and the implementation of your modules separate.
  88. : Keep the interface in .h files and the implementation in .c files.  This
  89. : fits neatly into C's limitations.
  90.  
  91. : What I want to see in the next standard is a better way of exporting
  92. : module interfaces to other modules which can't be abused in the way that
  93. : header files tend to be.
  94.  
  95. : --
  96. : |    Neil Gall, Hewlett-Packard Ltd, Queensferry Telecoms Operation,   |
  97. : |          South Queensferry, Scotland  +44 (0)131 331 7112            |
  98. : | neilg@hpsqf.sqf.hp.com    http:/www.tardis.ed.ac.uk/~chrism/neil/nb/ |
  99. : |             "That's what it'll be like in the future..."             |
  100.  
  101. --
  102. *********begin r.s. response**********
  103.  
  104.     what practical difference
  105.     is there
  106.     between
  107.         .c
  108.     and
  109.         .h
  110.     in this?
  111.  
  112. *********end r.s. response************
  113. Ralph Silverman
  114. z007400b@bcfreenet.seflin.lib.fl.us
  115.  
  116.